1. Field of the Invention
This invention generally relates to measuring performance of a computer system. More specifically, the invention relates to measuring performance of a logically partitioned computer system on a per logical partition basis.
2. Background Art
Logical partitioning (LPAR) is a system structure which allows a symmetric multiprocessor (SMP) system to be subdivided into “partitions”, also known as “zones”, each of which contains the necessary processor, memory, and input/output (I/O) resources to run an operating system (OS) image. LPAR provides easy redeployment of computing resources to support changing workloads without the need for physical restructuring, flexible growth to accommodate increased workloads, and large, scalable single-system-image enterprise systems.
Because LPAR breaks the traditional model of one operating system running on one hardware platform, LPAR generates the need for a set of platform management functions that operate outside the scope of any single operating system image. This need has been met by the introduction of a set of platform management functions implemented in firmware and hardware.
These platform management functions have been implemented in a firmware hypervisor with underlying support from millicode, i390, and hardware. The hypervisor is a firmware resident application, or set of applications, that manages virtual machines and logical partitions. The hypervisor is responsible for many aspects of partition management including allocating resources to a partition, installing an operating system in a partition, starting and stopping the operating system in a partition, dumping main storage of a partition, communicating between partitions, and other partition management functions.
As an example, one logically partitionable computer system that has achieved widespread commercial success is the Zseries eServer offered by the International Business Machines Corporation, Armonk, N.Y.
In order to get the maximum performance out of a computer system, that performance may be monitored and measured. The results of these measurements can be used to modify the hardware, firmware, and software design to improve future performance. With a logically partitioned computer system, performance measurement teams often have access to only a single zone. The workloads to be measured are dispatched on Logical Processors within this Zone. For this reason, the measurement teams are only interested in the performance data collected while the hardware is executing on behalf of the Zone or Zones of Interest (ZOI).
As a more specific example, instrumentation and sampling is the name given to the mechanism used to measure the performance of the IBM zSeries eServers. This task is achieved by repeatedly executing “workload” instruction streams (often segments of actual customer workloads targeted to stress particular hardware/software functions) and collecting data relevant to the system's performance. Initially hardware captures selected signals and stores them in hardware arrays. Each group of these selected signals is called a Sample. When enough Samples are captured to fill the arrays, firmware (zSeries millicode and i390 code) is invoked to move the data from the arrays to storage. A rich set of controls allows the user (a measurement team member) great flexibility in selecting which signals are captured and when the selected data is captured. This data is later used for the analysis of important metrics such as CPI (cycles per instruction), cache misses/hits, pipeline stalls, etc.
Since the data-capturing hardware exists on each physical processor, historically, the data has been collected and stored on a per-physical-processor basis. A buffer area in storage was allocated for each physical processor, and the data from each processor was stored in its own dedicated buffer. Thus, Instrumentation data was collected for the entire machine, including all Zones on every measurement. To allow a measurement team to identify the data that was collected while the hardware was executing on behalf of the ZOI, the current Zone Number was included in each Sample. After the measurement had finished, the data underwent further processing to include only data pertinent to the ZOI.
There are three major drawbacks to this method. Firstly, a large amount of storage (which is costly) is required to store data for the entire machine. The latest zSeries machines can have as many as 64 physical processors installed. The ZOI could, for example, run on a single physical processor, thus, only one byte in 64 would be of interest with the remainder ultimately being discarded. Secondly, additional machine and human resources are utilized during the filtering step. Lastly, running with Instrumentation active has performance and RAS impacts. Although these impacts are relatively small, it would be preferable for the Instrumentation measurement to have no impact outside of the ZOI. In implementations to date, all Zones are running with Instrumentation active; therefore all Zones suffer these impacts.